众所周知，C/C++执行效率高，但难以驾驭，开车一时爽，但稍不留神容易翻车。估计每个C/C++程序员都遭受过内存泄漏的困扰。本文提供一种通过wrap malloc查找memory leak的思路，使得你翻车的时候能够自救，而不至于车毁人亡。
内存泄漏就是动态申请的内存丢失引用，造成没有办法回收它（我知道杠jing要说进程退出前系统会统一回收），相当于在人身上轧个口子，伤口一直流血不止，关键这口子还不知道轧哪儿。
内存泄漏对于客户端应用可能不是什么大事，而对于长久运行的服务器程序则可能是致命的。
Java等傻瓜式编程语言会自动管理内存回收，你只管用，系统会通过引用计数技术跟踪动态分配的每块内存，在合适的时机自动释放掉，这种方式叫隐式释放，相当于车的自动挡。
而C/C++需要显式的释放，也就是开发者需要确保malloc/free配对，确保每块申请的内存都恰当的释放掉，相当于车的手动挡。有很多手段可以避免内存泄漏，比如RAII、比如智能指针（大多基于引用计数）、比如内存池。C/C++程序员也是蛮拼的，一直在跟内存泄漏做殊死搏斗。
理论上，只要我们足够小心，在每次申请的时候，都牢记释放，那么这个世界就清净了。但现实往往没有这般美好，比如抛异常了，释放内存的语句执行不到，比如模块之间的指针传递，又或者某菜鸟程序员不小心埋了颗雷，所以，我们必须直面真实的世界，那就是我们会遭遇内存泄漏。
我们可以review代码，double check，结对编程，但从海量代码里找到隐藏的问题，这如同大海捞针，谈何容易啊？兄弟。
所以，我们需要借助工具，比如valgrind，但这些找内存泄漏的工具，往往对你使用动态内存的方式有某种期待，或者说约束，比如常驻内存的对象会被误报出来，然后真正有用的信息会被掩盖在误报的汪洋大海里，所以，很多时候，valgrind根本解决不了日常项目中的问题，并没什么卵用。
很多著名的开源项目，为了能用valgrind跑，都大张旗鼓的修改源代码，从而使得项目符合valgrind的要求，用vargrind跑过没有任何报警叫valgrind干净，这倒也不失为一个一劳永逸的办法。
既然这些个玩意儿都中看不中用，所以，求人不如求己，还得自力更生，多大点事儿。
可以通过operator new/delete，operator new[]/delete[]重载，但这里有很细致的功夫，你需要全面了解，而不是贸然行动，建议看看Effective C++，对operator new系列操作符重载有专门的阐述。
你也可以hook malloc、free等c编程接口。
你还可以开启ptmalloc的调试功能，它有时候也能管点用。
动态内存分配器是介于kernel跟应用程序之间的一个函数库，linux glibc提供的动态内存分配器叫ptmalloc，因为抱了linux的大腿，故而是应用最广泛的动态内存分配器。
从kernel角度看，动态内存分配器属于应用程序层；而从应用程序的角度看，动态内存分配器属于系统层。到底属于哪一层，这取决于你的身份和角度。
应用程序可以通过mmap系统调用直接向系统申请动态内存，也可以通过动态内存分配器的malloc接口分配内存，而动态内存分配器会通过sbrk、mmap向系统分配内存，所以应用程序通过free释放的内存，并不一定会真正返还给系统，它也有可能被动态内存分配器缓存起来。
所以当你malloc/free配对得很好，但通过top命令去看进程的内存占用，还是很高，你不必感到惊讶。
google有自己的动态内存分配器tcmalloc，另外jemalloc也是著名的动态内存分配器，他们有不同的性能表现，也有不同的缓存和分配策略。你可以用它们替换linux系统glibc自带的ptmalloc。
new是c++的用法，比如Foo *f = new Foo，其实它分为3步。
通过operator new()分配sizeof(Foo)的内存，最终通过malloc分配。
在新分配的内存上构建Foo对象。
返回新构建的对象地址。
new=分配内存+构造+返回，而delete则是等于析构+free。
所以搞定malloc、free就是从根本上搞定动态内存分配。
每次通过malloc返回的一块内存叫一个chunk，动态内存分配器是这样定义的，后面我们都这样称呼。
gcc支持wrap，即通过传递-Wl,--wrap,malloc的方式，可以改变调用malloc的行为，把对malloc的调用链接到自定义的__wrap_malloc(size_t)函数，而我们可以在__wrap_malloc(size_t)函数的实现中通过__real_malloc(size_t)真正分配内存，而后我们可以做搞点小动作。
同样，我们可以wrap free。
malloc跟free是配对的，当然也有其他相关API，比如calloc、realloc、valloc，这些都是细节，根本上还是malloc和free，比如realloc就是malloc + free的组合。
我们会malloc各种不同size的chunk，也就是每种不同size的chunk会有不同数量，如果我们能够跟踪每种size的chunk数量，那就可以知道哪种size的chunk在泄漏。很简单，如果该size的chunk数量一直在增长，那它很可能泄漏。
光知道某种size的chunk泄漏了还不够，我们得知道是哪个调用路径上导致该size的chunk被分配，从而去检查是不是正确释放了。
我们可以维护一个全局 unsigned int malloc_map[1024 * 1024]数组，该数组的下标就是chunk的size，malloc_map[size]的值就对应到该size的chunk分配量。
这等于维护了一个chunk size到chunk count的映射表，它足够快，而且可以覆盖到0 ~ 1M大小的chunk的范围，它已经足够大了，试想一次分配一兆的块已经很恐怖了，可以覆盖到大部分场景。
那大于1M的块怎么办呢？我们可以通过log的方式记录下来。
在__wrap_malloc里，++malloc_map[size]
在__wrap_free里，--malloc_map[size]
如此一来，我们便通过malloc_map记录了各size的chunk的分配量。
不对，free(void *p)只有一个参数，我如何知道释放的chunk的size呢？怎么办？
我们通过在__wrap_malloc(size_t)的时候，分配8+size的chunk，也就是额外分配8字节，用起始的8字节存储该chunk的size，然后返回的是(char*)chunk + 8，也就是偏移8个字节地址，返回给调用malloc的应用程序。
这样在free的时候，传入参数void* p，我们把p往前移动8个字节，解引用就能得到该chunk的大小，而该大小值就是之前在__wrap_malloc的时候设置的size。
好了，我们真正做到记录各size的chunk数量了，它就存在于malloc_map[1M]的数组中，假设64个字节的chunk一直在被分配而没有被正确回收，最终会表现在malloc_map[size]数值一直在增长，我们觉得该size的chunk很有可能泄漏，那怎么定位到是哪里调用过来的呢？
我们可以维护一个toplist数组，该数组假设有10个元素，它保存的是chunk数最大的10种size，这个很容易做到，通过对malloc_map取top 10就行。
然后我们在__wrap_malloc(size_t)里，测试该size是不是toplist之一，如果是的话，那我们通过glibc的backtrace把调用堆栈dump到log文件里去。
注意：这里不能再分配内存，所以你只能使用backtrace，而不能使用backtrace_symbols，这样你只能得到调用堆栈的符号地址，而不是符号名。
如何把符号地址转换成符号名，也就是对应到代码行呢？答案是addr2line。
addr2line工具可以做到，你可以追查到调用链，进而定位到内存泄漏的问题。
至此，恭喜你，你已经get到了整个核心思想。
当然，实际项目中，我们做的更多，我们不仅仅记录了toplist size，还记录了各size chunk的增量toplist，会记录大块的malloc/free，会wrap更多的API。
总结
通过wrap malloc/free + backtrace + addr2line，你就可以定位到内存泄漏了。
本页共61段，4280个字符，9053 Byte(字节)